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Introduction 


This paper will address the issue of human factor aspects of civil flight deck certification, with 
emphasis on the pilot’s interface with automation. In particular, three questions will be asked 
that relate to this certification process: (1) are the methods, data, and guidelines available from 
human factors to adequately address the problems of certifying as safe and error tolerant the 
complex automated systems of modem civil transport aircraft; (2) do aircraft manufacturers 
effectively apply human factors information during the aircraft flight deck design process; and 
(3) do regulatory authorities effectively apply human factors information during the aircraft 
certification process? 


Problems with Automation 


Progressive automation is a feature of the modem civil cockpit and the trend toward more 
information, greater complexity, and more automated aircraft has the potential to significantly 
isolate the pilot from the aircraft resulting in less understanding and awareness. Billings (1991) 
reports that the dominant cause of aircraft accidents is human error and that the most important 
purpose automation can serve is to make the aviation system more error resistant and error 
tolerant. It is generally accepted that future developments in the civil flight deck environment 
will have substantial automation in order to provide cost-effective air transport. However, it is 
widely reported that the dominant factor in many civil aircraft accidents in the recent past has 
been automation and that automation has had a “debilitating” contributory role (Sheridan, 
1991). For example, 65 to 70 percent of civil jet transport accidents are attributed to human 
error and of that amount the majority were controlled flight into terrain (Hughes, 1989). 
Accidents caused by controlled flight into terrain (CFIT) are of particular concern to human 
factors, since a primary contributor appears to be the pilot interface with automated aircraft 
(Lenorovitz, 1992a, 1992b). 
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Pilots criticize flight deck design. Poor human factors are cited (although often not 
explicitly) as a contributing factor in a wide range of aircraft accidents. Often these problems are 
caused through the pilot’s interaction with “automation.” The Air Accident Investigation Branch 
(AAIB) report on the Boeing 737-400 accident at Kegworth, U.K. (Department of Transport, 
1989) noted that some time was lost as the copilot attempted unsuccessfully to program the 
flight management system (FMS) to produce the correct flight instrument display for landing at 
East Midlands Airport. From the cockpit voice recorder it is inferred that the first officer 
selected the route page and was entering the correct information (for the destination airfield) but 
as an enroute point. He did not notice the inadvertent selection nor understand the limitations of 
the available selections with respect to this information. An absence of appropriate feedback 
within the FMS allowed the error to remain. The first officer failed to select the arrival airfield 
page; this page is similar to the enroute data page in terms of data layout and data entry. In 
addition, there was no clear, unambiguous indication (e.g., a title) of the selected page within 
the FMS. The Airbus A320 FMS is also often criticized for not providing easy and efficient 
information access and selection. Pilots report having to select up to five different pages to 
obtain information necessary to complete a single action sequence. Both examples illustrate 
violations of well recognized, explicit guidelines that apply to the design of human-computer 
interfaces (HCI). 

The results of recent surveys addressing attitudes towards glass cockpits have shown that 
pilots report an erosion of flying skills, increased workload at critical times of flight, and a 
sense of being “out-of-the-loop” as a result of automation (McClumpha, James, Green, & 
Belyavin, 1991; Weiner, 1989). An analysis of the comments made by respondents of the 
Royal Air Force (RAF) Institute of Aviation Medicine’s (IAM) survey of pilots’ attitudes 
toward automated aircraft highlighted two main types of comments about the human-computer 
interface as it relates to civil flight deck automation (Rudisill, in press). One set of comments 
related to specific systems and specific problems with the HCI on the aircraft. Although this 
information is particular to an aircraft type, it indicates human factors problems that could be 
used to help develop human factors assessments required for a certification program. The other 
set of comments, however, related to the broader nature of automation and the difficulty pilots 
experience interacting with automated equipment. For example, pilots reported difficulty in 
knowing what the automation was doing, what the boundaries or limits of performance were, 
and how to intervene effectively if problems arose. Pilots also reported that many of these types 
of problems emerge only after considerable line flying or with specific experience in unusual 
situations. Exposure to these types of situations forces pilots to appraise their ability to 
understand and feel competent with automation. These issues are the ones that present 
considerable difficulty for manufacturers in terms of how to design aircraft systems and their 
pilot interfaces. Automation also presents difficulties for regulatory authorities in terms of how 
to certify designs as safe and error tolerant. 

Billings (1991) stated that only a subset of conditions and failures can ever be evaluated in 
systems as complex as modem civil flight decks. It is not, therefore, surprising that Weiner and 
Curry (1980) concluded that the rapid pace of automation is outstripping the pilot’s ability to 
comprehend all the implications for aircraft performance. They reported that an uneasy balance 
now exists between accepting aircraft in which all the implications and potential for debilitating 
behavior are unknown and, on the other hand, training to support crew tasks when operating 
these highly automated aircraft. 
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Civil Aircraft Design and Regulatory Authorities 


Regulatory authorities are responsible for providing certificates of airworthiness for all aircraft 
operating within their airspace. To that end, their role is to act as the arbiter for the aircraft 
acceptance process. They assure, among other things, that aircraft perform to engine power and 
thrust requirements and that airframe structures have appropriate mechanical integrity. They 
assess, to stringent requirements, the ability of aircraft to operate to a safe landing under 
circumstances unlikely encountered during normal flying. Therefore, the essence of regulatory 
authority certification is whether aircraft meet minimum acceptable standards identified as 
requirements for certification. The authority determines acceptance by defining a number of 
requirements and criteria and applying them during systematic aircraft evaluation. 

Aircraft manufacturers take great care in the design process leading to certification. The 
Boeing® 757™ flew 3,942 hours of simulator missions before certification in 1982. The 
Boeing 767™ program involved 5,348 hours of simulator flying and the 747-400 accumulated 
5,981 hours. A total of 369 pilots from 29 airlines flew the 747-400™ simulator and nearly 200 
non flying personnel were involved in the design process (Hughes, 1989). A regulatory 
authority may require more than 1,000 hours of simulator flying and over 100 actual landings 
before certificates of airworthiness are issued. There is no doubt that certification of civil 
aircraft by regulatory authorities is approached thoroughly, diligently, and carefully and that 
aircraft manufacturers are responsive to certification requirements and design for safe, error 
tolerant systems. 

Aircraft design, particularly flight deck design, is evolutionary. This evolutionary approach 
carries with it two strong implications from a human factors perspective. One is that a flight 
deck will not vary substantially from previous versions. This helps ensure that pilot training for 
that aircraft will be kept to a minimum (i.e., cost effective). The second and more disquieting 
implication is that flight deck design appears to have evolved without systematic adherence to 
any rigorous human factors scientific base and that this situation has been perpetuated through 
the evolutionary nature of aircraft design. Norman (1991) takes a strong position with regard to 
this issue. He argues that cockpit procedures, flight instruments, and regulations are “guided 
more by instincts, anecdotes, and reactions to individual incidents rather than by systematic, 
scientific analysis of the issues.” There appears to be a failure to comply with a basic tenet of 
human factors which dictates that the user interface (which, broadly defined in this context, 
includes procedures, instruments, and regulations) should be derived from an understanding of 
the tasks, procedures, and information requirements of pilots. This understanding and 
information should then be mapped to the interface design in a way that exploits the pilot’s 
sensory, perceptual, physical, and cognitive processes. However, certain flight situations (e.g., 
engine fire) require specific actions by crew members in clearly defined ways and the crew is 
legally responsible for following set operating procedures. Unfortunately, even in this 
situation, nowhere is it explicit that procedures, instruments, and regulations were derived from 
understanding the pilot’s task, procedures, and information requirements and subsequently 
mapped to the interface design so as to support the pilot’s cognitive activities. 

Existing certification requirements do, however, establish the need to provide specific 
information to the crew. Unfortunately, neither the form or content of information nor the 
pilot’s ability to access it easily and efficiently for required tasks appear as established 
certification requirements. A recent research program at the NASA Langley Research Center 
investigated information that pilots use and how long and when they use it. It is interesting that 
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fundamental research of this nature was only underway as late as 1991. A case could be made 
that there has been a fundamental shift on flight decks in the pilot interface from one that is 
essentially electromechanical to one that is largely software based and automated, consequently 
driving a need for research in this area. Nevertheless, the pilot’s task has not changed 
appreciably as a result of technology changes. Therefore, pilot information requirements have 
remained essentially unchanged and should have served as the basis for design, independent of 
final implementation technology. 

Neither is there apparently a requirement levied on the aircraft designer by the regulatory 
authority for an aircraft design to conform to detailed and explicit requirements for good quality 
human engineering. The specific number of hours flown and/or tested in a development and 
certification program is not necessarily an indication of good design. On the other hand, what is 
examined, found, and remedied during the design process is of greater interest. Information, 
though, on the form and content of specific human factors examination does not appear readily 
available. More specifically, the pilot interface with aircraft systems does not appear to have 
been subjected to rigorous and critical examination based on existing human factors and human- 
computer interaction methods, standards, or guidelines. There is evidently no requirement to 
systematically evaluate the aircraft for adherence to good human factors criteria. 

The certification authority, as the arbiter of civil aircraft acceptability, maintains 
responsibility for ensuring that the pilot interface provides the necessary facilities for safe flight. 
Besides ensuring aircraft conformance to the traditional requirements such as appropriate 
propulsion and structural integrity, they should also establish pilot interface conformance 
requirements that rely on good quality human engineering based upon established human 
factors design principles. Mechanisms and processes to evaluate human factors systematically 
do not appear to be in place with the authorities; it is suggested that they be established to help 
foster sound human factors flight deck design. 

The certification process is flexible enough to allow a manufacturer to request a derogation 
from the certification requirements. Derogation or relaxation of requirements can be permitted at 
the discretion of the regulatory authority, but only when it is considered safe to do so. The 
question asked by a regulatory authority is whether an aircraft is likely to be as safe as a 
previous version. Unfortunately, human factors requirements are strong candidates for 
derogation because of the often subjective and generally implicit nature of human factors 
evaluation. There is also a concern with the possible cumulative effect on pilot performance of 
numerous separate derogations. The possible effect of any derogation on the pilot’s ability to 
operate the aircraft safely should to be considered as part of the derogation analysis. However, 
as a result of the generally subjective nature of the human factors assessment, particularly with 
regard to HCI, it is perhaps not surprising that human error is identified as the major 
contributory factor in aircraft accidents. 

We have described the exacerbating effects of progressive automation and the apparent 
absence of systematic human factors practice in the design of civil aircraft flight decks. The 
apparent absence of systematic evaluation of human factors by regulatory authorities for aircraft 
certification has also been commented upon. Two questions now remain: 1) is information 
available within the human factors community to support the processes of flight deck design 
and aircraft certification, and 2) what is required to achieve the goal of incorporating human 
factors into design and certification processes? 
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Role of Human Factors 


The domain of classic human factors contains concepts, principles, and methods that are 
sufficiently objective and advanced to meet the need for certifying aircraft to specific standards, 
requirements, and criteria. This information is derived from the scientific base of experimental 
psychology, human factors, and physiological research. It describes human sensory, 
perceptual, and motor performance, and, to a lesser degree, cognitive performance. This 
empirically-based information is potentially available for the analysis and certification of 
sensory and perceptual characteristics, manual operation, and physical effects (e.g., noise, 
vibration, anthropometry, biomechanics) operating within the pilot interface environment. For 
example, anthropometric design standards can precisely define acceptable reach requirements 
for appropriate percentiles of the population. It would be highly unusual to design an aircraft 
flight deck that prevented the pilot from reaching required controls and displays. Neither would 
regulatory authorities certify such a design. A detailed knowledge of vision and character 
readability allows the equally precise definition of alphanumeric font size based on the seated 
eye position of the pilot and copilot. Reach envelopes, workspace layout, display readability, 
and the acceptable limits of force functions can all be predicted, established, evaluated, and 
certified, and specific consequences of derogation can be predicted. Many references are 
available for the design of these system characteristics and these could be adapted for use in 
certification programs (e.g., Boff & Lincoln, 1988; Department of Defense, 1989). 

The situation is rather different for design and certification of the aircraft human-computer 
interfaces on today’s automated civil aircraft. Automation per se and software-based interfaces 
in general have changed the locus of control within the cockpit from the physical domain to the 
cognitive domain. Therefore, much of the HCI today on the flight deck is related to human 
cognitive performance and it is this particular domain of performance that presents the true 
challenge for certification programs effectively dealing with human factors. 

To date, regulatory authorities have generally based examination on theory and models 
followed by testing to criterion performance. Hence, mathematical modeling is used to predict 
the likelihood of system failure. There are two problems with this approach when applied to 
human factors certification, especially certification of the HCI. First, mathematical modeling 
will be used to predict the failure of individual elements of the system to a lO -8 error rate. 
Assessment of human error as a result of system design is the domain of certification test pilots 
who will assess how critical a potential error is likely to be. An assessment may suggest that a 
system has a low error rate and is therefore acceptable. What does not appear to be assessed, 
however, is the contribution of the error potential of an individual system component with all 
other aircraft systems nor the effects of combinations of errors created through poor interface 
design. It is unclear if mathematical modeling is an appropriate technique for modeling or for 
predicting failures of the pilot-vehicle interface. Indeed, the approach generally taken during 
HCI design involves designing the interface according to established good design practices 
rather than modeling after design and then assessing error potential. 

It is our contention that regulatory authorities do not yet possess the understanding to 
effectively review or assess the demands that cognitive systems require. A typical “fallback” 
position of a regulatory authority is to adopt the “blame and train” philosophy. Human error is 
often treated as a training issue rather than as a reflection of underlying design deficiencies (cf. 
recommendation from AAIB report on Kegworth accident). However, the difficulty with this 
reasoning is that current methods and practices used by regulatory authorities do not appear to 
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address the human-computer interface aspects of system design. Furthermore, they do not 
appear to support the process in a manner that can lead to improved understanding of potential 
problems and subsequent establishment of standards and requirements for design for reference 
by manufacturers. The cognitive aspects of system performance require very different methods 
and techniques from those applied to the classic domains of human engineering and impose 
unique methods for certification. The current form and status of HCI science requires a 
substantial change by regulatory authorities in terms of flight deck HCI design philosophy. 
These issues are dealt with in the following sections. 


Contributions of Cognitive Psychology 

In a paper addressing the role of cognitive psychology in designing useful and usable systems, 
Landauer (1991) addresses current limitations of theory. He suggests that a theory of human 
computer interaction good enough to allow prediction of system characteristics for design is 
likely to be impossible because of the complex behavior of systems and the cognition 
supporting user interaction with the systems. Landauer argues that laws, such as Hick’s law, 
Fitts’ law, and laws of visual and auditory perception, have indeed made an impact, albeit 
minor. The emphasis of this reasoning is that a theory that allows predictions and design 
decisions from domains other than classic human factors is unlikely to be available for some 
time, if ever. 

The data, methods, tools, guidelines, and standards that would serve as the bases for 
analysis of more cognitive aspects of pilot operations and design of HCIs to support them do 
not yet exist in a form readily usable for certification. In a sense this is understandable given the 
complex nature of the underlying psychological domain. As has already been mentioned, 
sensory and perceptual processing and manual control are complex behaviors, but they are also 
more amenable to direct investigation. Systematic investigation of cognitive processing and 
development of coherent theories has occurred only recently. A base of objective data, 
sufficiently complex unifying theories of cognition, and an appreciation for how this 
information should be reflected in an HCI are now being formalized. 

However, what is presently available for use in HCI design and certification is an explicit 
representation of what constitutes good HCI design practice, with supporting methods and 
validated guidelines and standards based on substantial supporting research. This work occurs 
in several forms: (1) a software design model that explicitly identifies HCI design tasks and 
requires iterative prototyping and review, (2) HCI guidelines and standards that embody 
principles of good HCI design derived from empirical research, and (3) instruments and 
methods, such as HCI checklists and usability testing tools, that may be used for HCI 
evaluation and certification. This approach can provide the foundation for effectively integrating 
HCI knowledge into civil flight deck design and certification processes. 


HCI and the Design Model 

A feature often incorporated within the military weapon systems procurement cycle is an 
explicit model of a design that includes consideration of HCI within the design cycle. The 
models require iterative HCI design, with prototyping and formal assessments integrated 
throughout the design cycle. Requirements for acceptance test procedures are also identified 
early. The basic, general procurement model is: (I) concept studies, (2) feasibility analysis, (3) 
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project definition, (4) development, (5) build, and (6) in-service support. Human factors can, 
in principle, be integrated into this cycle at each stage with differing specificity and 
requirements at each stage. For example, NATO Standardization Agreement 3994 AI (NATO 
Headquarters, 1993) is an example of a procedural guide for integrating human engineering into 
system design and evaluation. 

At present, the civil transport aircraft model of procurement and production is different and 
includes various roles and responsibilities for system designers, airlines, and regulatory 
authorities. There is apparently no explicit requirement for HCI prototyping and review by the 
user population. Certification typically occurs late in the design and development process and 
certification approval will be sought during the final phase of the development program. 
Furthermore, certification is formally planned late in the development schedule. If a problem is 
identified at this stage, it is usually too late to either address the problem adequately or 
implement a redesign. However, it is noted that certifying authorities can participate in reviews 
during the aircraft design process. In this way, design features that would prevent certification 
of the aircraft could potentially be noted and corrected. 

The international nature of aircraft manufacturing, purchasing, and regulation exacerbates 
the problem. Typically, a regulatory authority from a country other than that of the airframe 
manufacturer will not formally interact with the manufacturer until the point at which 
certification is required. Experience from work with military systems procurement strongly 
suggests that this approach is likely to be problematic and issues identified at this stage of 
certification are usually too costly to remedy. The development model for civil flight deck 
design needs to be updated to include explicit consideration of the HCI. Aircraft regulatory 
authorities should more actively participate in the design and development process. 


HCI Guidelines and Standards 

A trend within the human factors industry has been the development of standards for human 
computer interfaces. In recognition of the importance of a user’s interface with a system, Apple 
Computers requires that all applications for their products adhere to their HCI guidelines and 
standards. Recently other HCI guidelines and standards have been published and are becoming 
widely used in commercial applications (e.g.. Open Software Foundation [OSF] Motif™; Open 
Look™; Presentation Manager™). 

A design practice that has emerged on projects involving software-based systems is the 
provision of both project-specific and general HCI guidelines and standards. The purpose of 
the guidelines and standards is to provide a human factors-based, well designed, common HCI 
across all user-system interfaces. The guidelines and standards can be levied on all system 
components even if produced by several suppliers. However, this explicit HCI design practice 
does not appear to be well integrated into the airframe manufacturers’ flight deck design 
approach or the regulatory authorities’ acceptance testing and certification procedures. Evidence 
indicates that numerous designers are unaware of many relevant HCI design guidelines and 
standards. Evidence also suggests that many designers view guidelines and standards as a 
hindrance constraining design rather than an aid providing structure and boundaries to good 
design practice. 

Airframe manufacturers’ problems are further compounded because flight decks consist of a 
mix of avionics from a range of suppliers. Each separate avionics subsystem supplier is 
unlikely to have either in-house guidance for HCI design or its own proprietary standard for the 
“look and feel” of the system. Major airframe manufacturers integrate many subsystem 
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components into a “coherent” whole, yet little or no effort is made to create a common look and 
feel across equipment groups. Often a flight deck will consist of a multitude of HCIs, a unique 
one for each piece of avionics hardware (e.g., there are cases where two different keyboard 
layouts exist on the same flight deck). Many general HCI design guides and standards are 
available that could be used for flight deck HCI design and certification (e.g., Boff & Lincoln, 
1988; Department of Defense, 1985; Department of Defense, 1989, sec. 5.15; National 
Aeronautics and Space Administration, Space Station Freedom Program Office, 1991 ; Smith & 
Mosier, 1984). 


HCI Evaluation Methods: Checklists and Usability Testing 

Many HCI guidelines and standards can be represented as high level HCI evaluation criteria 
embodied within checklists. HCI checklists help formalize design evaluation by domain experts 
(i.e., h uman factors HCI design practitioners). For example, Ravenden and Johnson (1990) 
identify nine checklist criteria: visual clarity, consistency, informative feedback, explicitness, 
appropriate functionality, flexibility, control, error prevention and correction, and user guidance 
and support. There are over 100 checklist questions and the answers help provide a 
standardized and systematic method enabling those evaluating an interface to identify problem 
areas. Shneiderman (1986) identifies 20 major items in a short generic user-evaluation 
questionnaire for interactive systems. The Shneiderman questionnaire identifies a range of 
questions with bipolar semantically-anchored items that require users to evaluate aspects of 
system performance. The preceding examples are representative of generic audits and can be 
used in a variety of ways. 

Usability testing has become one of the most well established methods of product evaluation 
used by human factors engineers. A recent series of studies funded under the European 
Strategic Program for Research in Information Technology (ESPRIT) Project 5429 (1992), 
referred to as MUSIC (Metrics for Usability Standards in Computing), have examined and 
identified methods and tools to measure the usability of products that require human computer 
interaction. It is not the intention of this paper to review HCI procedures but to simply point out 
that considerable work has been underway for some time in this area, that information is 
available, and that it is sufficiently refined for direct application to civil aviation. 


Organizational Implications 


The point was made earlier that regulatory authorities will need to adjust to different 
requirements imposed by cognitive elements of a system for effective design assessment and, 
hence, certification. At an organizational level, though, the form and function of human factors 
also need to be addressed. Rouse (1991) argues for the concept of human-centered design and 
makes two important points. He suggests that not only are the concepts, principles, and 
methods in human factors not sufficiently advanced, but, more importantly, that most current 
principles have little impact on design. This, he argues, is a result of the massive influence of 
the organization in general and the structure within which human factors is allowed to function. 
There are obvious parallels with Billings’ (1991) human-centered approach to automation. 
Whereas Billings refers to users primarily as pilots. Rouse takes a system-oriented view and 
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refers to users as any stakeholders within the ultimate system (e.g., regulatory authorities, 
airlines, maintainers, sales staff, pilots, and others). Rouse argues that human factors will have 
greater impact when these wider implications are considered. To this end we believe that 
regulatory authorities require a substantive change in philosophy concerning human factors. 
Four organizational changes are required. 

The first organizational change is to recognize and integrate general human factors 
developments, particularly HCI design, into aircraft design and certification processes. In fact, 
this is a key message of this report. There is ample evidence that pilots, engineers, and systems 
designers typically do not understand the benefits that can accrue with a formal human factors 
evaluation. Regulatory authorities also need to recognize the unique contribution of human 
factors and formally establish a mechanism for its incorporation into the certification process. It 
should also be recognized that the HCI scientific base can be of a qualitatively different form 
than other more entrenched certification areas. In addition, regulatory authorities can set 
requirements by specifying good quality human factors and HCI design, even if these are 
established at a high level. Designers will have to attempt to meet those requirements or provide 
substantial, appropriate data for consideration of relaxing them. If this approach is adopted, 
examples of poor HCI design in civil cockpits may, in time, begin to disappear. A better 
representation of aviation and, particularly, non-aviation, related but immensely applicable, 
standards and guidelines needs to be achieved. 

A second organizational modification concerns the model used for flight deck HCI design 
and the stage at which certification occurs. The detailed form and content of human factors 
certification support should be defined and established. Regulatory authorities should start early 
in the process and review the technicalities and implications of an aircraft’s design. National 
regulatory authorities outside the manufacturer’s home country should also be given 
consideration for reviewing proposed aircraft designs during the design process. 

The third organizational change involves end users. Line pilots who daily operate the 
systems and who must interact with their aircraft through interfaces provided by the 
manufacturer should be formally involved in some way in the HCI review process. Neither 
aircraft manufacturer test pilots nor airline managers, who may be pilots themselves, can 
adequately represent typical line pilots’ operational requirements. 

Finally, the fourth and perhaps most ambitious requirement may be incorporation of expert 
human factors practitioners as regulatory authority “sign-off’ administrators, as well as the 
manufacturer’s design team to ensure that human factors is given appropriate consideration. 


Conclusions 


Pragmatically, it is assumed that aircraft design methods will not change unless regulatory 
authorities establish requirements and criteria for design verification that induce an aircraft 
manufacturer to change its organization; in fact, the regulatory authority itself must also change. 
To foster these changes, integration of knowledge from other human factors domains, other 
than those specifically related to aviation, must occur. The knowledge is in the form of a design 
approach that explicitly incorporates human factors and HCI considerations and uses 
empirically-based design guidelines and standards. In addition, the use of formal assessment 
methods and tools for usability testing and certification assessment must be applied. This paper 
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mentioned the potentially valuable contributions from HCI studies and usability assessments; 
the form and content of that intervention was also described. 

Additionally, a number of organizational alterations are required to allow application of data 
and methods for aircraft design and certification. Norman (1989) would argue for a complete 
revision of the aircraft design process. Such a revision is probably untenable. The effective 
management of H F in the civil aircraft certification process is the more tenable option and 
probably implies “a little and often.” We recommend that regulatory authorities establish a better 
appreciation of the nature and form of HCI assessment. In particular, an appreciation of the 
type of assessment demanded by cognitive systems must be developed. There is also a strong 
case for encouraging regulatory authorities to examine systems and subsystems early in the 
design process. Authorities must also establish effective HCI requirements. Finally, formal 
recognition of the unique human factors contribution in the form of sign-off authority should be 
established. The preceding approaches are needed in order to ensure appropriate integration of 
human factors in the certification process for civil flight deck design. 

The position of this paper is that a number of changes are required to the aircraft design 
process and the aircraft certification process in order to enhance flight deck HCI design. These 
changes include the use of a software design model which explicitly considers the HCI, 
empirically-based guidelines and standards during HCI design, and instruments and methods 
like checklists and usability testing tools for HCI evaluation and certification. This approach can 
provide the foundation for effectively integrating HCI knowledge into the civil flight deck 
design and certification process. 

(The views expressed in this paper are those of the authors). 


References 


Billings, C. (1991). Human centered aircraft automation: A concept and guidelines (Report 
No. NASA TM 103885). Washington, DC: National Aeronautics and Space Administration. 
Boff, K. R., & Lincoln, J. E. (Eds.). (1988). Engineering data compendium (Vols. I-3H). 

New York: J. Wiley and Sons. 

Department of Defense. (1985). Human engineering guidelines for management information 
systems (DOD-HDBK-761). Washington, DC: Author. 

Department of Defense. (1989). Human engineering design criteria for military systems , 
equipment , and facilities (MEL-STD 1472D). Washington, DC: Author. 

Department of Transport. (1989). Report on the accident to Boeing 737-400 G-OMBE near 
Kegworth , Leicestershire on 8 Jan 1989 (Air Accident Investigation Report No. 4/90). 
London: Her Majesty’s Stationery Office. 

European Strategic Program for Research in Information Technology (ESPRIT) Project 5429. 
(1992). Metrics for usability standards in computing (MUSIC). Teddington, Middlesex, 
U.K.: National Physical Laboratory. 

Hughes, D. (1989, August 7). Human factors research aids and glass cockpit design effort. 

Aviation Week & Space Technology , pp. 34-36. 

Landauer, T. (1991). Let’s get real: A position paper on the role of cognitive psychology in the 
design of humanly useful and usable systems. In: J. Carroll (Ed.), Designing Interaction 
(pp. 60-73). Cambridge, England: Cambridge University Press. 


Certification for Civil Flight Decks... 


299 


Lenorovitz, J. M. (1992a, February 3). Confusion over flight mode may have role in A320 
crash. Aviation Week & Space Technology , pp. 29-30. 

Lenorovitz, J. M. (1992b, March 2). French government seeks A320 changes following Air 
Inter crash report. Aviation Week & Space Technology , pp. 30-3 1 . 

McClumpha, A., James, M., Green, R., & Belyavin, A. (1991). Pilots’ attitudes to cockpit 
automation. Proceedings of the Human Factors Society 35th Annual Meeting, 1 , 107-1 11. 

National Aeronautics and Space Administration, Space Station Freedom Program Office. 

(1991). Human computer interface guide (SSP 30540). Reston, VA: Author. 

NATO Headquarters. (1993). Application of human engineering to advanced aircrew systems 
design (NATO Standardization Agreement 3994 AI, Edition 1). Brussels: Author. 

Norman, D. (1989, July). The "problem" of automation: Inappropriate feedback and 

interaction, not "overautomation" (ECS Report 8904). San Diego: University of California, 
Institute of Cognitive Science. 

Norman, D. (1991). Cognitive science in the cockpit (Vol. II, No. 2). Dayton, OH: Wright- 
Patterson Air Force Base, Crew Systems Ergonomics Information Analysis Center 
(CSERIAC). 

Ravenden, S., & Johnson, G. (1990). Evaluating usability of human-computer interfaces: A 
practical method. New York: J. Wiley and Sons. 

Rouse, W. (1991). Design for success: A human-centered approach to designing successful 
products and systems. New York: Wiley. 

Rudisill, M. (in press). Pilot comments concerning the interface to automation: results from the 
RAF IAM survey (NASA Technical Report). 

Sheridan, T. B. (1991). Automation, authority, and angst-revisited. Proceedings of the 
Human Factors Society 35th Annual Meeting, 7, 2-6. 

Shneiderman, B. (1986). Designing the user interface: Strategies for effective human-computer 
interaction. Reading, MA: Addison Wesley. 

Smith, S., & Mosier, J. N. (1984). Design guidelines for user-system interface software (MTR 
No. 9420). Hanscom Air Force Base, MA: Mitre Corporation. 

Weiner, E. (1989). Human factors of advanced technology (glass cockpits) transport aircraft 
(NASA Report CR 177528). Washington, DC: National Aeronautics and Space 
Administration. 

Weiner, E., & Curry, R. (1980). Flight deck automation promises and problems (NASA TM 
81206). Washington, DC: National Aeronautics and Space Administration. 



300 



